如果你正在推进私有化 AI 项目，先别急着看 GPU 报价单。

有一种可能你完全没考虑过：你估算的算力，根本跑不动你要部署的模型。

很多团队在立项时拍脑袋：“买个 4090 就够了”“上两张 A100 肯定没问题”“国产卡便宜，先买几台试试”。结果模型一部署，要么显存爆了，要么首 token 等 10 秒，要么并发一上来直接卡死。硬件买回来了，退不了，换不了，项目进度卡住了。

你所有的预算、部署方案、ROI 测算，全都建立在一个前提之上：你对本地推理算力的估算是对的。

本地推理算力到底是怎么回事？

大模型本地推理分两个阶段：Prefill（预填充） 和 Decode（解码）。

Prefill 阶段，模型一次性处理你输入的整段 prompt，计算量大、并行度高，属于算力密集型。Decode 阶段，模型一个 token 一个 token 地往外吐，每生成一个 token 都要把模型权重和 KV Cache 读一遍，属于内存带宽密集型。

你可以把本地推理想象成一家餐厅厨房。Prefill 是备菜——一次性把一堆食材切好、配好，考验的是厨师团队的整体算力。Decode 是炒菜——一份一份出餐，每出一份都要重新拿调料、看菜谱，考验的是厨房动线和取料速度。你的 GPU 算力再强，如果内存带宽不够，出餐速度照样上不去。

当用户问 AI 一个问题时，发生的过程是：输入被 token 化，经过 Prefill 生成第一个 token，然后进入 Decode 循环，一个 token 一个 token 输出，直到结束。首 token 延迟叫 TTFT，每个输出 token 的延迟叫 TPOT。用户体验好不好，就看这两个指标。

而且私有化 AI 项目和云端 API 不同。云端可以弹性扩容，你本地买多少卡，就只能跑多少并发。买少了业务扛不住，买多了预算浪费。算力估算，就是在这两者之间找平衡点。

不是所有 AI 项目都需要本地推理

在你急着算 GPU 算力之前，先搞清楚一个事实：不是所有场景都适合私有化本地推理。

有些场景用云端 API 更划算：业务波动大、模型更新快、并发不稳定、团队没有运维能力。有些场景必须本地：数据不能出内网、延迟要求极高、长期成本敏感、需要深度定制模型。

即使确定要本地推理，也要区分：

• 是实时交互还是离线批处理？实时交互看延迟，离线批处理看吞吐。

• 是小模型还是大模型？3B、7B、14B、32B、70B，硬件需求差几个数量级。

• 是单并发还是高并发？并发数直接决定 KV Cache 占用和总显存。

• 是FP16还是INT8/INT4？量化能大幅降低显存，但可能损失精度。

• 是单卡还是多卡？多卡涉及张量并行、流水线并行、互联带宽。

所以算力估算不是“买最贵的卡”，而是“在满足业务 SLA 的前提下，找到成本最低的配置”。这是两个完全不同的目标。

怎么估算本地推理算力？

方法不复杂，但需要一步一步来。

第一步：明确模型和场景

先写下这些参数：

• 模型参数量 P（比如 7B、14B、32B、70B）

• 精度（FP16、INT8、INT4）

• 层数 L、隐藏维度 H、注意力头数、KV 头数

• 最大输入长度、最大输出长度

• 目标并发数

• 可接受的 TTFT 和 TPOT

• 业务峰值 QPS

这些数字越具体，估算越准。

第二步：估算显存

显存是本地推理的第一道门槛。显存不够，直接跑不起来。

权重显存：

text

权重显存 = 参数量 P × 每个参数字节数

FP16：2 字节；INT8：1 字节；INT4：0.5 字节。

例如 7B 模型：

• FP16：约 14GB

• INT8：约 7GB

• INT4：约 3.5GB

KV Cache 显存：

text

KV Cache = 2 × 层数 L × KV头数 × head_dim × 序列长度 × 并发数 × 字节数

如果是 MHA，KV 头数等于注意力头数；如果是 GQA/MQA，KV 头数更少，显存更省。

简化估算（MHA）：

text

KV Cache ≈ 2 × L × H × 序列长度 × 并发数 × 字节数

框架开销：
CUDA Context、激活值、临时缓冲区、推理引擎开销，通常再留 1-3GB 或总显存的 10%-20%。

总显存：

text

总显存 = 权重 + KV Cache × 并发 + 框架开销

举例：7B INT8 模型，权重 7GB，序列长度 4096，并发 8，KV Cache 可能 4-8GB，加框架开销，总显存约 14-18GB。一张 24GB 的 4090 可以跑，但并发再高就危险。

第三步：估算算力

推理 FLOPs 的粗略公式：

text

每 token 前向 FLOPs ≈ 2 × P
总 FLOPs ≈ 2 × P × (输入 token 数 + 输出 token 数)

例如 7B 模型，输入 512 token，输出 512 token：

text

总 FLOPs ≈ 2 × 7e9 × 1024 ≈ 14.3 TFLOPs

如果要求 1 秒内完成，实际算力利用率 30%：

text

所需峰值算力 ≈ 14.3 / 1 / 0.3 ≈ 47.8 TFLOPS

但注意：Decode 阶段不是一次性算完，而是逐 token 生成。算力需求被拆散，实际瓶颈往往在内存带宽，而不是峰值算力。

第四步：估算内存带宽

Decode 阶段，每生成一个 token，都要把权重和 KV Cache 读一遍。

text

带宽需求 ≈ (权重字节数 + KV Cache 字节数) × tokens/s

例如 7B INT8 权重 7GB，目标 20 tokens/s：

text

带宽需求 ≈ 7GB × 20 = 140GB/s

RTX 4090 带宽约 1TB/s，单并发够用。但如果并发 10，KV Cache 变大，带宽需求可能翻几倍。

带宽不够，算力再高也白搭。

第五步：估算并发和吞吐

text

总吞吐 tokens/s = 并发数 × 每请求生成速度

并发数受限于显存：

text

最大并发 ≈ (总显存 - 权重 - 框架开销) / 每并发 KV Cache

同时要考虑 batch size。Batch 越大，吞吐越高，但 TTFT 和 TPOT 可能变差。实时交互场景要控制 batch，离线批处理可以拉高 batch。

第六步：匹配硬件

根据以上结果，看 GPU/NPU 的：

• 显存容量

• 显存带宽

• FP16/INT8 算力

• 互联带宽（多卡）

• 功耗和散热

• 驱动和框架支持

消费级卡（RTX 4090/5090）适合中小模型、低并发、预算有限。专业卡（A100/H100/L40S）适合大模型、高并发、企业级。国产卡适合信创要求，但生态和工具链需要重点验证。

第七步：算 TCO，不只看采购价

总拥有成本包括：

• 硬件采购

• 电费：功率 × 24 × 365 × 电价

• 散热和机柜

• 运维人力

• 折旧和更换周期

• 软件授权和适配成本

一张 400W 的卡，一年电费可能就上千元。十张卡三年电费可能超过一张卡的价格。

算力估算错误通常就这几个坑

第一，只看参数量，不看 KV Cache。 7B 模型权重 14GB，你以为 16GB 显存够，结果序列一长、并发一高，KV Cache 直接把显存撑爆。

第二，只看算力，不看带宽。 算力 100 TFLOPS，但带宽只有 200GB/s，Decode 阶段照样慢。大模型推理，带宽比算力更关键。

第三，忽略量化精度。 FP16 跑不动就上 INT8，INT8 跑不动就上 INT4。但量化可能掉精度，业务能不能接受，要提前测。

第四，忽略并发。 单并发测试很快，一上生产 10 个并发直接卡死。KV Cache 是并发杀手。

第五，忽略 Prefill 和 Decode 差异。 Prefill 吃算力，Decode 吃带宽。用同一个指标衡量两个阶段，估算必然偏。

第六，忽略框架利用率。 理论算力 100 TFLOPS，实际推理框架可能只用到 30%-50%。vLLM、TensorRT-LLM、ONNX Runtime、TGI，不同框架效率不同。

第七，忽略网络和存储。 模型加载速度、多卡通信、日志写入、数据读取，都可能成为瓶颈。

第八，忽略未来模型增长。 今天跑 7B，半年后想上 14B，显存和算力直接翻倍。采购时不留余量，后面只能再买。

第九，忽略电力和散热。 多卡机器不是插上电就能跑。电源功率、插座、空调、机柜承重、噪音，都是问题。

第十，忽略软件生态。 卡能买到，驱动和推理框架不一定支持。国产卡尤其要验证 PyTorch、vLLM、TensorRT 的适配情况。

算力估算错误会造成多大的损失？

这取决于项目阶段。

如果是测试阶段，估算错了大不了重买，损失的是时间和预算。

如果是生产部署，估算错误的代价就大了：

买大了。 花了几百万买卡，实际利用率不到 20%。电费、机柜、运维都在烧钱，ROI 算不过来。

买小了。 业务一上线就卡，并发上不去，用户投诉。加卡？机箱插槽不够、电源不够、预算不够。项目延期，业务方失去信心。

买错了。 卡不支持需要的框架，或者驱动不兼容，或者国产卡生态不成熟。硬件在机房里吃灰，团队天天填坑。

扩展困难。 单卡能跑，多卡通信效率低。张量并行、流水线并行调不通，大模型部署不了。

数据安全风险。 为了省算力，把数据传到云端 API，违反合规要求。这个损失不是钱能衡量的。

算力估算和你的 AI 战略是一回事

很多企业在做私有化 AI 时，把硬件采购当成 IT 部门的事。业务部门提需求，算法部门选模型，IT 部门买卡——各管一段。

这种割裂的后果是：算力估算没人对最终结果负责。 业务不知道显存和带宽，算法不知道预算和电力，IT 不知道模型迭代速度。最后买回来的卡，跑不动模型，或者利用率极低。

硬件采购不是孤立的，它和你的业务场景、模型选型、数据规模、合规要求、成本预算、运维能力全部相关。算力估算不是一道数学题，而是一次跨部门的需求对齐。

实操：怎么一步步估算和采购

①业务场景和 SLA 对齐。 问清楚：多少用户？峰值 QPS？可接受延迟？数据能不能出内网？模型多久更新一次？

②列出模型清单和参数。 参数量、精度、层数、序列长度、并发数。不要只写“大模型”，要写具体型号和版本。

③计算显存需求。 权重 + KV Cache × 并发 + 框架开销。留 20% 余量。

④计算算力和带宽需求。 用公式粗算，再用实际框架跑 benchmark 校准。

⑤确定硬件档位。 单卡还是多卡？消费级还是专业级？进口还是国产？显存优先，带宽其次，算力第三。

⑥做 POC 测试。 找供应商借卡，用你的真实模型、真实数据、真实并发跑一遍。测 TTFT、TPOT、吞吐、显存占用、功耗、稳定性。

⑦算 TCO。 硬件 + 电费 + 散热 + 运维 + 折旧 + 软件适配。对比云端 API 成本，看几年回本。

⑧分批采购。 先买 20%-30% 验证，再补齐。不要一次性 all in。

⑨建立监控和扩展方案。 上线后监控 GPU 利用率、显存、温度、延迟、吞吐。预留扩展接口和预算。

⑩定期复盘。 每季度看一次：模型有没有变大？并发有没有增长？算力够不够？成本合不合理？

私有化 AI 硬件采购，说复杂也复杂，说简单也简单：算清楚显存，算清楚带宽，算清楚并发，留足余量，做 POC，算 TCO。 这六件事想明白了，算力估算就不会差太远。